analysis platform, which is built in conjugation to Wireshark.
A little bit introduction.
My name is Nishant Sharma.
I work for Pentester Academy.
Before being a security researcher, I was a developer.
I was developing Wi-Fi access points for enterprises,
as well as the Wi-Fi security systems.
I have a master's degree in InfoSec.
And for the last couple of years, I have been presenting my research
at Black Hat USA, Black Hat Asia, DemoLabs, HITB, and all the other venues.
Here are my team members.
Let me introduce them.
Hello, everyone.
My name is Ashish.
I work for Pentester Academy as a senior security researcher.
Before joining Pentester Academy,
I've worked for law enforcement agencies as a cybercrime investigator.
And I've been in this industry from last eight years.
My work has been presented in Black Hat USA, Black Hat Asia,
DEF CON USA, and this time in DEF CON China to present Wireshark.
Hello, DEF CON.
My name is Jeswin.
I'm currently working as a security researcher at Pentester Academy.
And my work has been presented at Black Hat Asia, USA, and DEF CON DemoLabs.
And here I am to present Wireshark.
So those of you who do not know about Pentester Academy,
it's an online portal which is completely dedicated to security-related courses.
As it is online and it is subscription-based,
you can subscribe to it and you can access 40-plus of our courses
which are completely focused on security.
We also run attackdefense.com.
Which is an online browser-based cyber range.
Once you sign up for this, you can actually get access to 1,000-plus of labs
which are spread over 65 categories.
The reason for mentioning attackdefense here is because we even have a community section
which is free for all.
You guys can go and check those challenges out.
You can play those for free.
So now coming to the topic at hand,
we are going to discuss Wireshark.
But before diving into it,
before going to the main tool,
we are first going to cover the basics of VoIP.
Then we will see how to recover or reconstruct the VoIP call.
After that, we will take a look on the current state of open-source tools
that are out there that you can use.
And we will conclude the talk by introducing Wireshark,
that is our contribution to the community and the field.
When we talk about VoIP telephony,
this is the thing that is going to eventually replace PSC.
This is going to replace PSTN completely.
PSTN is your classic phones.
You know, you have your dedicated lines connected to exchanges.
You pick up the phone.
You dial the number.
What it does in the back end is it reserves a circuit for you.
And after, you know, the call is complete,
only then the circuit is destroyed.
Because you are reserving this circuit,
it is not that efficient.
Another reason why this is not the best solution
is because when you are doing all of this,
you have to do,
analog to digital conversion two times.
So because your VoIP run on IP,
and so it can use packet switching.
So that's the reason why most of the enterprises
and now even telecom providers are moving toward your VoIP.
We are not going to talk about proprietary protocols,
but only the open source standards that are in making,
and they are on the way to take over the industry as well.
So we are going to talk about SIP in general.
These are three protocols that you will learn about
when we talk about the signaling protocols of VoIP.
So VoIP has two major parts.
One is the signaling, and the other one is the media carrier.
Signaling defines when the phone will ring,
when you will disconnect the call.
All of that control operation is done by signaling protocol.
The actual voice or the video,
when you are making,
the call is then handled by the media carrier,
that is RTP in this case.
So we are only going to focus on the first one here,
that is, sorry, that is the SIP.
And the other protocols are proprietary,
so we are not going to talk a lot about them.
SIP, or the Session Initiation Protocol,
is the signaling one.
It's a text-based protocol,
and it supports your audio calls as well as video calls.
So as I already mentioned,
when we say it supports these calls,
it is only being used for the controlling.
It cannot carry your data or media.
It can carry your SMSs,
because they are text-based data, right?
So it can work there.
It is important to mention that SIP by default is not secure.
It does not provide any kind of transport layer security.
So if you want to secure your SIP communication,
you have to use TLS with it.
So just like you do for HTTP, right?
You have to use SIP over your TLS.
This is the model in which your VoIP telephony work,
especially in SIP case.
When you join the network or when you join the system,
your phone will actually register to one of the servers,
the VoIP servers,
and that is done by using the subscribe message.
So after that is done,
if you want to place a call, you will be pushing
a message to the server and then that message will be forwarded to the target
party so that is how you will place a call when any other party want to call
you you are going to get a notify message because you have subscribed to
the service this is a simple floor chart of a call between two parties the first
party when they initiate the call at an invite packet SIP invite packet is sent
after the other party picks up it gets the acknowledge after that your media
transfer takes place and a buy packet is sent by the party who disconnects the
call so now these are the user agent servers which we can use any servers
which you may like in our case we have used asterix because it's open source it
has a very good documentation and
that's the most popular one so and to place a call we need a soft phone or a
hardware phone right so there are some commercial soft phones available and
they do have a free version of that we have used micro shift to capture all the
traffic right so and we have used asterix now so what is asterix now
asterix now is the asterix server which will handle all the back-end stuff
signaling and on our calling etc the free PBX will allow us to manage and
control the asterix server using the graphical interface right to demonstrate
different configurations we have taken the wipe traffic capture in the
in this simple setup so this setup involves a scenario where there are two
clients and a server and all of the void traffic is going through the server
now when it comes to wipe setup to enforce security we can achieve that in
different ways for example in one case we can have sip packets encrypted in
another case we can have RTP packet encrypted so these are the four
possible scenarios when it comes when we encounter wipe traffic analysis so the
first one is sip and RTP where both sip as well as RTP packets are unencrypted
the second case is sip over TLS and RTP and as the name suggests sip packets are
sent over TLS and RTP packets are unencrypted in the third case we have
sip packets unencrypted and SRTP is used instead of RTP
and in fourth case we have sip packet sent over TLS and SRTP is used instead
of RTP so we'll take a look at the first case which is sip and RTP so now
sip as DP packets contain all of the information which is required to set up
the RTP stream and if encryption is enabled the encryption key will also be
present in the SDP packet
TCP packets provide the statistics and control information of the RTP session
and RTP packets carry the media so now wireshark has a really beautiful feature
which allow us to analyze the flow sequence of wipe call so this is how the
flow sequence of a wipe call between two client will look like so starting from
the invite packet start how the call was initiated till the end of the call
wireshark also has an option to play the wipe calls so we can easily play
using RTP player of wireshark so as he explained if you are using sip plus RTP
that's the simplest form that you can use there is no encryption if you have
the packet capture your wireshark out of the box can actually reconstruct the
call you can play the call so you know life is good
but what if some part of the call is encrypted so in the second scenario when
you use a sip plus SR TP your RTP packets are now encrypted so you can
still see the SIP packets as you can see here you can also observe the key
that is being used by SR TP to encrypt the traffic so we are talking about the
media traffic here so whatever you are saying whatever the video is going all
of that is encrypted but you are able to
see the key but the problem is in this case now your wire shard cannot decrypt it it can see the
key but it cannot decrypt it and if you look for rtp traffic instead of getting the rtp traffic
you are going to see the srtp traffic now the issue is when you will try to reconstruct the call
you will get something like this so this is how an encrypted protocol will look like because
you know the data is randomized you should not be able to make any sense of waveform from it and
you know this is doing it pretty well we cannot tell what kind of waveform it is
what are other configurations in other configurations you can protect your sip
by using the tls and you can leave the rtp out right so in that case you won't be able to see
sip packets because they are over tls right you will be able to see tls traffic a lot
so
now in this case even when rtp is not encrypted you are not going to see it why because your
wireshark actually relies on sip packets to figure out which udp packets are actually the rtp packets
so because now it cannot see the sip packets it cannot tell the difference between a normal udp
packet or your rtp packet but in this case if you observe the traffic you will find out that from
one port there is a lot of udp packets and if you follow the stream you should be able to make
sense out of it once that is done you can use decode as function of wireshark and by setting
decode as to rtp you can still recover the call there you go right so this is the proper waveform
and if you play it it will play you will be able to see listen whatever was you know whatever was
passed
so this is the super case of all right you have your encrypted sip and then you have your encrypted
srtp so in this case because you know your your wireshark will not be able to see the sip or the
rtp it's a little hard but the possibilities when you are using tls in this case is either
going to be one of two either your tls handshake is going to use your diffie hellman exchange
or it is going to use your rsa based handshake that is the private and public key thing right
so if it is using dhe dhe is pretty secure you know if you have collected a passive traffic sample
you cannot find out the key from it because dhe protects you against eavesdropping
but if you can do active mitm attacks you can actually target these two
but we are not covering the active side we are only talking about the passive side here
this diagram actually explains how dhe works i am not going to go into details
but it is here so that you guys can refer to it later similarly you have your rsa based public and
private key pairs which are used so our observations when we were doing all of
these experiments were that if dhe is used there is nothing you can do because we are only seeing
the passive traffic right we don't want to do the active attacks when rsc is being used if you have
the private key of the server that is being used for void transaction you can actually go ahead and
decrypt all of this and wireshark has a functionality for this but before that you have to understand
which of the method is being used so for that if you check your tls handshake you should be able to
see something like this or you can see here right it will tell you if it is using the diffie hellman
similarly
of rsa you will be able to see rsa handshake so once that is done once you use your
wireshark to decrypt this traffic you can go ahead and decode srtp as well
but if your srtp is not decrypted it will again look like this so this is how it will look like in
case of rsa so this is the field from where you will be able to tell if the rsa is being used
or the dhe
so the srtp is showing that you have already decrypted the ssl traffic
traffic from the ssl part so if you want to see how it looks like before performing any action
we should be able to anticipate if it is going to succeed or not right otherwise there is no
reason of you know doing blind experiments so if dhe is there there is nothing we can do
so now coming to the ssl part if you guys have already decrypted ssl traffic you already know
about it
from the edit preference option if you look for the protocols if you go to SSL
protocols it actually gives you an option to put a private key there if you
do that it will decrypt the traffic for you and once the SIP is decrypted you
can see the SITP key and by using other tools you can try to decrypt it now the
issue is there are two tools here and I'll let my colleague explain it that's
actually really quick mon SRTP Decrypt is a tool to decrypt SRTP stream so this
is the github repository and now let's take a look at how we can install SRTP
Decrypt SRTP Decrypt requires certain libraries to be pre-installed on the
system and once we have installed these libraries we can clone the repository
and use the make to compile it now this is a big
limitation of SRTP decrypt
decrypt that it do require a Linux system with build tools installed to use make.
Once we are done with the compilation, we'll have a ready to run SRTP decrypt binary. However,
this binary is not smart enough to figure the encryption key on its own.
So we do require to pass the encryption key as a parameter to the tool. We can
find the encryption key in the crypto parameter of the STP packet.
We also have to make a note of the UDP ports which were used by the SRTP stream.
So let's take a look at how we can use the tool. So since we already have the key and the input
file, we can directly feed it to the binary and it will generate an output in form of hexdump.
This is how the hexdump would look like. We can then use wireshark to import the hexdump
and recover the RTP.
So we do have to specify the UDP port information here as well.
So once the import has been completed, what you'll notice here is the timestamp as well as the IP
address, both source and destination have been modified. This is because SRTP decrypt do not
preserve the metadata. And in SRTP decrypt, the generated hexdump did not have any SIP packets. As a
result, wireshark is unable to figure out that a UDP packet is actually an RTP packet.
So you'll have to manually decode UDP packets RTP packet.
Once we have decoded the UDP packets RTP packets, we can then perform stream analysis on it.
And if we'll try to play the decrypted call,
what what you'll notice here is the waveform is not visible. This is again because the metadata was
not preserved by SRTP decrypt. However, if you click on the play button, you'll
still be able to hear the voice. So as you saw, the issue with this tool is
first you have to need a Linux system. You have the Linux system, now you have
to install the build tools, you have to compile it, and after that only you can
run it. And after going through this whole tedious process, in the end again
the metadata was not preserved. And if you are into forensics and everything
you know, right? IP addresses and timestamp is the most important thing. So
we cannot lose them. Another tool that we have is the libSRTP. It was created by
Cisco. It is available, it is open source. Just like the other tool, it also needs
you to use Linux. Once you have your Linux, you can clone it and then you can
do the configuring, make it, and after that it is
ready to run. So that's it. Thank you.
ready to use. Now just like the tool that we discussed about, the SRTP decrypt, this
tool also does not know how to decrypt it automatically. So you have to feed it
the key. And this one is even complex than the other one, because in this one
you have to first filter out the stream that you want to decrypt. So whenever you
are placing a VoIP call, whenever you are calling someone, there are always two
streams.
On one RTP stream, whatever you are saying, that data will go or that audio will go. On
the other stream, the other party, whatever he is saying, that audio will come. So in
this case, you have to first identify which stream you want to decrypt. You have to then
find the corresponding key, copy that, and pass that to the tool, right?
So this is the filtering part. You filter it, you export that stream as a PCAP, and
now you can run.
And after doing that, it will give you output in this format that is actually text. So you
have to again make it into a PCAP format. And for that, we are using text to PCAP tool.
So it is converting the timestamp that is in front of the packet. That's all it is doing.
So when you use both of these in conjugation, after that, you are able to see the SRTP decrypted
form.
And once that is there, you have to then again decode.
You can record it as your RTP.
And once you do that, you can then see the waveform.
This, right?
But also, in this case, you are not able to preserve the IP addresses or the timestamps.
So that's a big no-no.
And you already you have already seen the process, right?
It was .
And the idea of making this tool, the wipe shark, right?
It came when we were working on creating a new course for our company that was based on wipe security.
It came when we were working on creating a new course for our company that was based on wipe security.
So we were actually using these tools and that's when we realized that there should be something which is easier than these, which can be used by other people on platform of their choice, right?
No one should be forced to use a platform which they don't like for some reason.
Then there are other artifacts which are important when we talk about the security in VoIP, like your DTMF, the messages.
And then one more function that you need is the exporting call function, which is then used to analyze the call in other softwares, right?
So if you guys don't know about the DTMF, so whenever you call your credit card company or whenever you interact with any kind of IVR system, it asks you to press 1, 2, 3 on your dial pad, right?
So that is DTMF.
So whenever you are pressing 2, something like this is going through the route if you're using VoIP.
If you're using your PSTN, then obviously that's different.
Similarly, if you send SMSs over VoIP, your SIP protocol is going to carry those and this is how it will look.
So now if you want to export the calls and if you want to do forensics on that, you need to convert it into the waveform.
So my colleague will explain how to do that.
So now we want to...
We want to convert the RTP stream to WAV format.
So there is one online service which we can use and convert the RTP stream to WAV.
We just need to upload our PK file and submit it for the process.
Then it will convert the RTP stream to the WAV and we can download it on our local system.
Then we can play it using any media player such as VLC or Audacity, right?
So if you are more concerned about our privacy, right?
So we don't want to upload the PK app online.
So there is a script written in Bash, right?
And it uses Tshark and Shock.
And that's the GitHub link.
It does the same job.
And that's the tool help option.
So we need to make sure that...
Before we run the script, we need to install Tshark and Socks on our system.
Then we can run the script by passing as a first argument the PK app.
And in the second argument, we can mention the output file name.
And if you can notice in the snapshot, there's two files generated, right?
So that's our WAV file.
And if you notice in the directory...
In the directory of the script.
So before and after running the script.
Before we can't...
There is only two files, right?
Because we haven't run the script.
So after we run the script, there is a three file has been generated.
And we can actually play it using any media player as I just said.
And we can actually hear the call.
So enough of problems now.
Let's talk about the solution.
That's the interesting part.
And that is our contribution to this field.
And that's where we bring in our tool, that is WipeShark.
As you guys can guess easily that the Wipe part came from Wipe.
And the Shark part is taken from Wireshark.
Because the tool is created in form of the plugins of Wireshark.
Now there's a reason and I'm going to explain it.
Why instead of creating a separate tool, why we chose to go with this route.
Wipeshark can decrypt your Wipe calls whenever possible.
So by that I mean...
Whenever it will be able to see the decryption keys or the encryption keys in your SIP packets,
it will automatically decrypt it.
It can run on live traffic.
It has GPL license just like your Wireshark.
So now the next question is, do we really need it?
We talked about a lot of problems and some of them were the tools that we already have.
They are cumbersome to use.
Not everyone can use them.
You have to install them.
Then you have to go through the TDS process and then you can get the decrypted stream, right?
Another thing was these were restricted to Linux systems.
You have to use Linux.
Because the process was so tedious, it is more likely for the users to make mistakes.
Because you have to select the right key, then you have to select the right stream in some cases.
And after doing that, they were not maintaining or retaining
your metadata, that is your IP addresses and the timestamp, right?
Another problem with those, as you already saw, is that the input that those tools take,
that is not live traffic.
That is a captured PCAP that is passed to them after manual processing, right?
So our Wireshark can do all of this.
And that's why we think it can actually help people who are doing wipe analysis.
Why Wireshark plugins?
Because we all love Wiresharks.
Whoever is there in network analysis field, he has seen it, he has used it, and he knows
the kind of power Wireshark has, right?
So we decided if we create other tools, just like the other tools, you have to again install
it and then it will become platform dependent.
And then we have to also take care, because we are dealing in packets here, right?
So packets can be in the magnitude of thousands and even, you know, hundreds of thousands.
So why not to use Wireshark's specialty?
They have created Wireshark only for this purpose.
Another reason is we want this tool to be extensible.
So instead of going for C or any other compiled language, we chose Lua.
Lua is a very user-friendly language.
It's more of a scripting language with power of C.
So if you join any scripting language that you think, like your Python or something,
it has the power of C and it has the flexibility of Python.
And even in case of Python, if you want to run it, you need to, you know, you have to
run it and interpret it.
In this case, if you are using it in Wireshark plugins, you just need to paste the plugins
in the plugins directory in Lua itself.
You need not to compile it.
You need not to do anything.
It will run out of the box.
And because your Wireshark is OS independent, so are our plugins.
It will run on Windows, Mac, you know, Linux, you name it.
On any platform on which you can run your Wireshark, our system will run.
Thank you.
So Wireshark plugins are basically of two types.
One is the listener one.
Other one is the dissector one.
We are using both in our toolkit.
And this is how the typical dissection takes place in Wireshark.
You pass it packet.
It has a chain of dissectors.
So if you have used Wireshark, you know what I'm talking about.
Because when you get the packet, you have these layered layers there, right?
You have Ethernet layers, then the IP layer, then the TCP, and then the above layer like
HTTP.
So that is what exactly is happening there.
So first, whenever the packet is captured, it is passed to Wireshark.
The first plug-in or the first part to get this packet is the outermost layer.
So in this case, it will be the Ethernet.
So Ethernet header will be processed there, and the payload will be passed down to the
second one in the chain.
So in this case, you are chained plug-in swap.
So our Wireshark is also plugged.
It will be in the chain like this.
It takes after once your UDP and TCP parser is done.
So from TCP and UDP parser phase, it figures out if the packet is SIP, RTP, SRTP, or SDP.
It will pass it to the Wireshark chain, and then Wireshark will do something which looks
very complex here.
I'm not going to explain all of this.
We have a detailed research paper, which will be available on the GitHub repo.
You can go through it.
If you are interested in knowing the internal workings, you can refer to this.
If you have any questions, we will be reachable on mail also.
Similarly, this is the decryption routines for SIP traffic decryption.
And this is how you install Wireshark.
You just go to our GitHub repo.
You copy it and just paste it in the plug-ins folder.
And to find the plug-ins folder, just open your Wireshark, go to the help section.
From there, you have to go to the about Wireshark.
And now we have installed Wireshark.
And folders.
So, you will find personal plug-ins folder there.
Just open that folder.
Put our stuff there.
And it will work out of the box.
Yeah, you have to restart the Wireshark, not the whole system.
So once that is done, suppose this is your SRTP traffic, right?
So now we have installed Wireshark.
This is your SRTP traffic.
Just go to edit preferences.
So if you guys have already decrypted WiFi traffic or SSL traffic, then you can start
you know what i'm talking about you go to edit from edit you have preferences option from there
in protocol section you have to look for wipe shark so that is the new entry that we have created
once you install the plugin once you copy the plugins into the folder
and once you tick the box there so there was this little box here this one right just tick it it is
not ticked by default because you know if you don't want to decrypt it we also don't want to
once you do that you click ok and there you go that's all you have to do to decrypt the RTP
traffic and after that you can actually create waveform format now coming to the other problem
that we had we want to export the call in a popular format audio format right so that you
can use your audacity or other tools on it so for that we have provided this option here from the
tools menu if you go to the tools menu you can see that we have a lot of options here so for that
go to the wipe section you will see the export a peak wipe wave option and you can export it from
there it will ask you if you want to define a custom location or the file prefix if you don't
then it will use the default one and then it will export all the streams that are there in the
pcap so we have also appended IP addresses of source and destination so that you can keep track
of all of this one more thing that we wanted to be out there was something which can provide you
summary of your wipe traffic so suppose you are capturing this traffic on a network router or
switch right so now you are dealing with hundreds or thousands of calls so you want to know which
people are placing the calls which numbers are there all of that is needed right so what we did
we also created some more plugins which will do all of that for you so this one is the DTM
F so anyone if he was using RTP which was the unencrypted version if he has passed anything on
DTMF it will be logged and our plugin will show it in a pop-up right similarly you have your
extensions so these extensions are actually the numbers so this one here the extension is the
number if a username is associated with it that will also be shown with the IP address and also
with the user agent user agent is the software
that you are using to place the call now this information can help attackers in all of other
ways also right so similarly we can see how many RTP packets were transferred which can help us to
to quantify if it is an audio call or video call or how long it was right so all of the information
that was needed from the security perspective that's the only thing that we have covered we
haven't gone for the basic sip then again when you
connect to the server the sip server you have to register to the server and just to make sure that
no one can use your extension there is this password that you have to pass so if you want
to brute force some users password just copy this string this one is hashcat compatible so
you can just copy it and run hashcat on it and if the password is weak it will break
we can also see the servers or the proxies that are being used for wipe the messages the
sms's which are which were passed and the last part of the toolkit is to detect attacks so
suppose someone is running some attacks on your setup and you have the traffic capture you want
to know if some of the VoIP attacks are being launched first one is the brute forcing if
someone is trying to brute force your password our plugin can actually detect that by checking
the number of tries in a given threshold of time similarly invite flooding can be detected so
invite flooding is like calling someone again and again so whenever you place a call an invite message
is sent from the caller to the callee now think about it you send the same message like thousand
times what will happen his phone will ring he will pick the phone up he will put the phone down
the phone will again ring so it's kind of DOS or irritation attack right so it can detect that it
can detect the message flooding if you are spamming someone
and it can also see if someone is trying to do active mitm on your calls on the local network
it can also detect if any unauthenticated user is there so now we will see a little bit demo of how
to decrypt the srtp protocol and how to export the calls using our tool can we have the demo please
yeah so there we go
uh first one is to decrypt the srtp traffic you have this capture here which has sip plus srtp
traffic so if you search for sip you should be able to see the packets but when you search for
rtp you will be able to see the srtp traffic that is the encrypted one so what we are trying
to do here is we are trying to reconstruct the rtp stream to listen to the audio and this is how it
is encrypted right so now what we can do in this case is from edit just go to the preferences part
from there in the protocols we have to look for wipe shark
so once there just tick the small box and click OK now depending on the number of packets
wire shark will take its time and it will give you the rtp packets so now with the click of this button
you have actually decrypted srtp and if you try to reconstruct the stream you should be able to
see the waveform in its proper form and you can play it so that's the first part and that's the
major contribution that we think we have done all of further is like the bonus then the second part
of this demo is in which we are exporting the wave files for each stream so that is also very easy you
just need to go to the tools option
from there go to wipe all the tools all the plugins you can find there this is again asking
you if you want to change the file prefix or if you want to change the location once that is done
it will export all the streams to this location with the prefix provided so that was our demo all
of these plugins will be there our research paper will be there on our GitHub repository that is this
one it is already
not up yet it will be up after the talk we have a tool visiting cards you can take those if you want
and if you have any questions I will be taking those now
any questions related to sip rtp srtp anything is welcome
so even if you think of something after the talk here is my email ID you can drop me a mail I will
revert to the mail I'll be happy to help you with you know whatever question you have so that concludes
our talk thank you for coming to our talk and thank you Defcon for giving us this opportunity thanks
